home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-heinanen-nhrp-00.txt < prev    next >
Encoding:
Text File  |  1993-08-24  |  23.3 KB  |  616 lines
  1.  
  2. INTERNET DRAFT                                             Juha Heinanen
  3.                                                          Telecom Finland
  4. Expires February 8, 1994                                 Ramesh Govindan
  5.                                                                 Bellcore
  6.                                                           August 8, 1993
  7.  
  8.  
  9.                 NBMA Next Hop Resolution Protocol (NHRP)
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet Draft.  Internet Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its Areas,
  16.    and its Working Groups.  Note that other groups may also distribute
  17.    working documents as Internet Drafts.
  18.  
  19.    Internet Drafts are draft documents valid for a maximum of six
  20.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  21.    other documents at any time.  It is not appropriate to use Internet
  22.    Drafts as reference material or to cite them other than as a
  23.    ``working draft'' or ``work in progress.''  Please check the 1id-
  24.    abstracts.txt listing contained in the internet-drafts Shadow
  25.    Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
  26.    ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
  27.    Internet Draft.
  28.  
  29. Abstract
  30.  
  31.    This document describes the NBMA Next Hop Resolution Protocol (NHRP).
  32.    NHRP can be used by a source terminal (host or router) connected to a
  33.    Non-Broadcast, Multi-Access link layer (NBMA) network to find out the
  34.    IP and NBMA addresses of the "NBMA next hop" towards a destination
  35.    terminal.  The NBMA next hop is the destination terminal itself, if
  36.    the destination is connected to the NBMA network.  Otherwise, it is
  37.    the egress router from the NBMA network that is "nearest" to the
  38.    destination terminal.  Although this document focuses on NHRP in the
  39.    context of IP, the technique is applicable to other network layer
  40.    protocols as well.
  41.  
  42. 1.  Introduction
  43.  
  44.    The NBMA Next Hop Resolution Protocol (NHRP) allows a source terminal
  45.    (a host or router), wishing to communicate over a Non-Broadcast,
  46.    Multi-Access link layer network (called NBMA for short), to find out
  47.    the IP and NBMA addresses of the "NBMA next hop" towards a
  48.    destination terminal.  The "NBMA next hop" is the destination
  49.    terminal itself, if the destination is connected to the NBMA network.
  50.  
  51.  
  52.  
  53. Heinanen & Govindan     Expires February 8, 1994                [Page 1]
  54.  
  55. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  56.  
  57.  
  58.    Otherwise, it is the egress router from the NBMA network is nearest
  59.    to the destination terminal.  Once the NBMA next hop has been
  60.    resolved, the source may either start sending IP packets to the
  61.    destination (in a connectionless NBMA network such as SMDS) or may
  62.    first establish a connection to the destination with the desired
  63.    bandwidth and QOS characteristics (in a connection oriented NBMA
  64.    network such as ATM).
  65.  
  66.    An NBMA network can be non-broadcast either because it technically
  67.    doesn't support broadcasting (e.g. an X.25 network) or because
  68.    broadcasting is not feasible for one reason or another (e.g. an SMDS
  69.    broadcast group or an extended Ethernet would be too large).
  70.  
  71. 2.  Protocol Overview
  72.  
  73.    In this section, we briefly describe how a source S uses NHRP to
  74.    determine the "NBMA next hop" to destination D.  S first determines
  75.    the next hop to D through normal routing processes.  If this next hop
  76.    is reachable through its NBMA interface, S formulates an NHRP request
  77.    containing the source and destination IP addresses, the source NBMA
  78.    address, and QOS information.  S then forwards the request to an
  79.    entity called the route server (RS).
  80.  
  81.    RSs are configured to cooperatively satisfy NHRP requests.  Each RS
  82.    "serves" a pre-configured set of terminals and peers with a pre-
  83.    configured set of RSs.  An RS exchanges routing information with its
  84.    peers (and possibly with the terminals it serves), using regular
  85.    routing protocols.  (However, an RS, unless it is also an
  86.    egress/ingress router, need not necessarily be able to switch regular
  87.    IP packets).  This exchange is used to construct a forwarding table
  88.    per QOS in every RS.  The forwarding table determines the next hop
  89.    from the RS for an NHRP request with the corresponding QOS.
  90.  
  91.    After receiving an NHRP request, the RS checks if it "serves" D.  If
  92.    so, the RS uses ARP [1] to find out D's NBMA address.  For the case
  93.    of an ATM network, the ARP operation is described in [2].  The RS
  94.    then either forwards the NHRP request to D or generates a positive
  95.    NHRP reply on its behalf.  The reply contains D's (D is S's NBMA next
  96.    hop) IP and NBMA address and is sent back to S.  NHRP replies usually
  97.    traverse the same sequence of RSs as the NHRP request (in reverse
  98.    order, of course).
  99.  
  100.    If the RS does not serve D, it extracts from its forwarding table the
  101.    next hop towards D.  If no such next hop entry is found, the RS
  102.    generates a negative NHRP reply.
  103.  
  104.    If the next hop is behind the RS's NBMA interface, the RS forwards
  105.    the NHRP request to the next hop.  If the next hop is behind some
  106.  
  107.  
  108.  
  109. Heinanen & Govindan     Expires February 8, 1994                [Page 2]
  110.  
  111. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  112.  
  113.  
  114.    other interface, the RS may be willing to act as an egress router for
  115.    traffic bound to D.  In that case, the RS generates a positive NHRP
  116.    reply containing its own IP and NBMA address (i.e., the RS is the
  117.    NBMA next hop from S to D).
  118.  
  119.    An RS receiving an NHRP reply may cache the NBMA next hop information
  120.    contained therein.  To a subsequent NHRP request, this RS might
  121.    respond with the cached, non-authoritative, NBMA next hop.  If a
  122.    communication attempt based on non-authoritative information fails, a
  123.    source terminal can choose to send an authoritative NHRP request.
  124.    RSs never respond to authoritative NHRP requests with cached
  125.    information.
  126.  
  127.    NHRP provides a mechanism to aggregate NBMA next hop information in
  128.    RS caches.  Suppose that RS X is the NBMA next hop from S to D.
  129.    Suppose further that X is an egress router for all terminals sharing
  130.    an IP address prefix with D.  When X generates an NHRP reply in
  131.    response to a request, it may replace the IP address of D with this
  132.    prefix.  The prefix to egress router mapping in the reply is cached
  133.    in all RSs on the path of the reply.  A subsequent (non-
  134.    authoritative) NHRP request for some destination that shares an IP
  135.    address prefix with D can be satisfied with this cached information.
  136.  
  137. 3.  Configuration
  138.  
  139.    Terminals
  140.  
  141.      In order to participate in NHRP, a terminal connected to an NBMA
  142.      needs to be configured with the IP address(es) of its RS(s).  The
  143.      RS(s) may be physically located on the terminals' default or peer
  144.      routers.  If the terminal is attached to several link layer
  145.      networks, it may also need to be configured to receive routing
  146.      information from its RS(s) so that the terminal can determine which
  147.      IP networks are reachable through the NBMA.
  148.  
  149.    Route Servers
  150.  
  151.      An RS is configured with a set of IP address prefixes that
  152.      correspond to the IP addresses of the terminals it is serving.
  153.      Moreover, the RS must be configured to exchange routing information
  154.      with its peer RSs (if any).  If a served terminal is attached to
  155.      several link layer networks, the RS may also need to be configured
  156.      to advertize routing information to such terminals.
  157.  
  158.      If an RS is acting as an egress router for terminals connected to
  159.      other link layer networks, the RS must, in addition to the above,
  160.      be configured to exchange routing information between the NBMA and
  161.      the other link layer networks.
  162.  
  163.  
  164.  
  165. Heinanen & Govindan     Expires February 8, 1994                [Page 3]
  166.  
  167. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  168.  
  169.  
  170.      In all cases, routing information is exchanged using regular intra-
  171.      and/or inter-domain routing protocols such as OSPF, Dual IS-IS,
  172.      BGP, or IDRP.
  173.  
  174. 4.  Packet Formats
  175.  
  176.    NHRP packets are carried either directly over the NBMA, encapsulated
  177.    in IP with a separate protocol number, or carried as ICMP messages.
  178.    Regardless, NHRP request and reply packets contain the following
  179.    fields:
  180.  
  181.        nhrp$op     1 byte          Operation code
  182.        nhrp$hc     1 byte          Hop count
  183.        nhrp$lnk    2 bytes         Link layer type
  184.        nhrp$net    2 bytes         Network layer type
  185.        nhrp$sll    1 byte          Length of source link layer address
  186.        nhrp$sla    sll/8 bytes     Source link layer address
  187.        nhrp$snl    1 byte          Length of source network layer address
  188.        nhrp$sna    snl/8 bytes     Source network layer address
  189.        nhrp$dnl    1 byte          Length of destination network layer address
  190.        nhrp$dna    dnl/8 bytes     Destination network layer address
  191.        nhrp$qosl   1 byte          Length of QOS information
  192.        nhrp$qos    qosl/8 bytes    QOS information
  193.        nhrp$dll    1 byte          Length of destination link layer address
  194.        nhrp$dla    dll/8 bytes     Destination link layer address
  195.        nhrp$onl    1 byte          Length of originator network layer address
  196.        nhrp$ona    pnl/8 bytes     Originator network layer address
  197.  
  198.    The Operation code indicates the type of the message.  The assigned
  199.    values are:
  200.  
  201.        NHRP Request                                =       1
  202.        NHRP Request for Authoritative Information  =       2
  203.        NHRP Positive, Authoritative Reply          =       3
  204.        NHRP Positive, Non-Authoritative Reply      =       4
  205.        NHRP Negative, Authoritative Reply          =       5
  206.  
  207.    If ICMP is used to carry NHRP requests and replies, then the
  208.    operation code determines the ICMP code.
  209.  
  210.    The Hop count indicates the maximum number of RSs that a request or
  211.    reply is allowed to pass before being discarded.
  212.  
  213.    The possible values for the Link layer type and Network layer type
  214.    fields are the same as for the Hardware type and Protocol type of ARP
  215.    [1] and may be found in the current Assigned Numbers RFC.
  216.  
  217.    All Length fields indicate the length of the corresponding entity in
  218.  
  219.  
  220.  
  221. Heinanen & Govindan     Expires February 8, 1994                [Page 4]
  222.  
  223. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  224.  
  225.  
  226.    bits.  An empty address or QOS field has a length 0.
  227.  
  228.    The QOS information field is network layer specific and is used to
  229.    select a forwarding table during query/request forwarding. For IP,
  230.    this field contains the desired TOS value.
  231.  
  232.    In requests and negative replies, the Destination link layer address
  233.    is always empty.  In a positive NHRP reply originating from an egress
  234.    router, the Destination network layer address may be a prefix of the
  235.    requested Destination network layer address.  Positive replies always
  236.    contain their originator's IP address.  If the originator's IP
  237.    address and the destination's IP addresses differ, the source
  238.    terminal may assume that the reply was generated by an egress router.
  239.  
  240.    An RS is not allowed to reply to an NHRP Request for Authoritative
  241.    Information with cached information, but may do so for an NHRP
  242.    Request.  Replies based on cached information carry a different
  243.    operation code from those based on authoritative information.
  244.  
  245. 5.  Protocol Operation
  246.  
  247.    The external behavior of an RS may be described in terms of two
  248.    procedures (processRequest and processReply) operating on two tables
  249.    (forwardingTable and cacheTable).  In an actual implementation, the
  250.    code and data structures may be realized differently.
  251.  
  252.    Each RS has, for each supported QOS, a forwardingTable consisting of
  253.    entries with the fields:
  254.  
  255.        <networkLayerAddrPrefix, outIf, outIfAddr, directlyConnected?>
  256.  
  257.    The networkLayerAddrPrefix field identifies a set of network layer
  258.    addresses known to the RS.
  259.  
  260.    The outIf field denotes either the server NBMA network interface or
  261.    some other link layer network interface.  If outIf denotes the served
  262.    NBMA interface, then two possibilities exist:
  263.  
  264.    (1) The RS is itself serving the networkLayerAddrPrefix.  This is
  265.    indicated by a true value in the directlyConnected? field and the
  266.    outIfAddr field has no meaning.  Such a forwardingTable entry has
  267.    been created by manual configuration.
  268.  
  269.    (2) Some other RS is serving the networkLayerAddrPrefix.  This is
  270.    indicated by a false value in the directlyConnected? field.  The
  271.    outIfAddr field now contains the NBMA address of the next hop RS.
  272.    Such a forwardingTable entry is a result of network layer address
  273.    prefix information exchange with one of the RS's peers.
  274.  
  275.  
  276.  
  277. Heinanen & Govindan     Expires February 8, 1994                [Page 5]
  278.  
  279. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  280.  
  281.  
  282.    If outIf denotes an interface other than the served NBMA interface,
  283.    then the RS may act as an egress router for the terminals sharing the
  284.    networkLayerAddrPrefix.  To do this it must be capable of switching
  285.    IP packets between the NBMA and the other link layer network.  Again
  286.    two possibilities exist:
  287.  
  288.    (1) The RS can itself resolve the link layer address corresponding to
  289.    the networkLayerAddrPrefix.  This is indicated by a true value in the
  290.    directlyConnected? field and the outIfAddr field has no meaning. Such
  291.    a forwardingTable entry has been created by manual configuration.
  292.  
  293.    (2) The networkLayerAddrPrefix is behind an RS in another NBMA or
  294.    behind some other router. This is indicated by a false value in the
  295.    directlyConnected? field.  The outIfAddr field now contains a link
  296.    layer address of this other router or RS.  Such a forwardingTable
  297.    entry is a result of networkLayerAddrPrefix information exchange with
  298.    one of the RS's peer routers or RSs in another NBMA.
  299.  
  300.    The protocol used to exchange networkLayerAddrPrefix information
  301.    among the RSs can be any regular IP intra- or inter-domain routing
  302.    protocol, such as OSPF, Dual IS-IS, BGP, or IDRP.
  303.  
  304.    In addition to the forwardingTable, each RS has for each supported
  305.    QOS a cacheTable consisting of entries with the fields:
  306.  
  307.        <networkLayerAddrPrefix, networkLayerAddr, linkLayerAddr>
  308.  
  309.    The entries in this table are learned from NHRP request and replies
  310.    passing through the RS.  The networkLayerAddrPrefix field identifies
  311.    a set of IP addresses sharing a common NBMA address that is stored in
  312.    the linkLayerAddr field. The networkLayerAddr field identifies the IP
  313.    address of the originator of the information.  It value differs from
  314.    networkLayerAddrPrefix only in case the originator is an egress
  315.    router.
  316.  
  317.    The cacheTable entries could also include a timeStamp field to be
  318.    used to age nnhopTable entries after a certain hold period.
  319.  
  320.    The following pseudocode defines how NBMA NHRP requests and replies
  321.    are processed by an RS.
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Heinanen & Govindan     Expires February 8, 1994                [Page 6]
  334.  
  335. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  336.  
  337.  
  338.      procedure processRequest(request);
  339.        addCacheTableEntry(request.sna, request.sna, request.sla);
  340.        let bestMatch == matchForwardingTable(request.dna) do
  341.           if bestMatch then
  342.              if bestMatch.directlyConnected? then
  343.                 if nbmaIf?(bestMatch.outIf) then
  344.                    let nbmaAddr == arp(request.dna) do
  345.                       if nbmaAddr then
  346.                          genPosAuthReply(request, request.dna, nbmaAddr)
  347.                       else
  348.                          genNegReply(request)
  349.                       end
  350.                    end
  351.                 else
  352.                    genPosAuthReply(replaceDna(request,
  353.                                       bestMatch.networkLayerAddrPrefix),
  354.                       selfNetworkLayerAddr, selfLinkLayerAddr)
  355.                 end
  356.              else
  357.                 if not requestForAuthInfo?(request) then
  358.                    let cacheMatch == matchCacheTable(request.dna) do
  359.                       if cacheMatch then
  360.                          genPosNonAuthReply(request,
  361.                             cacheMatch.networkLayerAddr,
  362.                             cacheMatch.linkLayerAddr);
  363.                          return;
  364.                       end
  365.                    end
  366.                 end;
  367.                 forward(request, bestMatch.OutIf, bestMatch.OutIfAddr)
  368.              end
  369.           else
  370.              genNegReply(request)
  371.           end
  372.        end
  373.      end
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389. Heinanen & Govindan     Expires February 8, 1994                [Page 7]
  390.  
  391. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  392.  
  393.  
  394.      procedure processReply(reply);
  395.        if posReply?(reply) then
  396.            addCacheTableEntry(reply.dna, reply.ona, reply.dla)
  397.        end;
  398.        if reply.sna == selfNetworkLayerAddr then
  399.           "reply is to the RS itself that is also acting as a terminal"
  400.        else
  401.           let bestMatch == matchForwardingTable(reply.sna) do
  402.              if bestMatch then
  403.                 if nbmaIf?(bestMatch.outIf) then
  404.                    if bestMatch.directlyConnected? then
  405.                       let nbmaAddr == arp(reply.sna) do
  406.                           if nbmaAddr then
  407.                              forward(reply, nbmaIf, nbmaAddr)
  408.                           end
  409.                       end
  410.                    else
  411.                       forward(reply, bestMatch.outIf, bestMatch.outIfAddr)
  412.                    end
  413.                 else
  414.                    "a request should never originate from another NBMA"
  415.                 end
  416.              end
  417.           end
  418.        end
  419.      end
  420.  
  421.    The semantics of the procedures and constants used in the pseudocode
  422.    are explained below.
  423.  
  424.    addCacheTableEntry(networkLayerAddrPrefix, networkLayerAddr,
  425.    linkLayerAddr) adds a new entry to the cacheTable or overwrites an
  426.    existing entry whose networkLayerAddrPrefix field is equal to
  427.    networkLayerAddrPrefix.  A new entry is not added if
  428.    matchCacheTable(networkLayerAddrPrefix) returns an entry whose
  429.    linkLayerAddr field is equal to linkLayerAddr.
  430.  
  431.    matchForwardingTable(networkLayerAddrPrefix) returns a
  432.    forwardingTable entry whose networkLayerAddrPrefix field is the best
  433.    match for networkLayerAddrPrefix or false if no match is found.
  434.  
  435.    nbmaIf?(outIf) tests if outIf is the interface of the served NBMA.
  436.  
  437.    arp(networkLayerAddr) performs ARP [1] on networkLayerAddr and
  438.    returns either the NBMA address corresponding to the networkLayerAddr
  439.    or false if no NBMA address is found.
  440.  
  441.    matchCacheTable(networkLayerAddrPrefix) returns a cacheTable entry
  442.  
  443.  
  444.  
  445. Heinanen & Govindan     Expires February 8, 1994                [Page 8]
  446.  
  447. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  448.  
  449.  
  450.    whose networkLayerAddrPrefix field is the best match for
  451.    networkLayerAddrPrefix or false if no match is found.
  452.  
  453.    genPosAuthReply(request, networkLayerAddr, linkLayerAddr) and
  454.    genPosNonAuthReply(request, networkLayerAddr, linkLayerAddr)
  455.    respectively generate positive authoritative and non-authoritative
  456.    replies by copying the request, rewriting the Operation code field,
  457.    initializing the Hop count field, filling in the Length of
  458.    destination link layer address and Destination link layer address
  459.    fields based on linkLayerAddr, and filling in the Length of
  460.    originator network layer address and Originator network layer address
  461.    fields based on networkLayerAddr.
  462.  
  463.    genNegReply(request) generates a negative, authoritative reply by
  464.    copying request, rewriting the Operation code field, and initializing
  465.    the Hop count field.
  466.  
  467.    replaceDna(request, networkLayerAddrPrefix) returns an NHRP request
  468.    where the Destination network layer address field of request is
  469.    replaced by networkLayerAddrPrefix.
  470.  
  471.    selfNetworkLayerAddr and selfLinkLayerAddr denote the egress router's
  472.    own IP and NBMA address in the served NBMA.
  473.  
  474.    requestForAuthInfo?(request) tests if request is a Request for
  475.    Authoritative Information.
  476.  
  477.    forward(request, outIf, outIfAddr) decrements the Hop count field of
  478.    request and forwards request to the address outIfAddr of the
  479.    interface outIf provided that the value of the Hop count field
  480.    remains positive.
  481.  
  482.    posReply?(reply) tests if reply is a Positive Authoritative or
  483.    Positive Non-Authoritative Reply.
  484.  
  485.    authoritativeReply?(reply) tests if reply is a Positive,
  486.    Authoritative Reply.
  487.  
  488.    nmbaIf denotes the NBMA interface of the RS.
  489.  
  490.    Similar to RSs, each terminal participating in NHRP has a
  491.    forwardingTable and a cacheTable.  The forwardingTable is the regular
  492.    forwarding table that the terminal is using for its IP routing.  The
  493.    terminal must, of course, be able to generate NHRP requests to its
  494.    RS(s) in case the forwardingTable shows that a particular destination
  495.    address is behind the NBMA interface and to process replies to these
  496.    requests.  The cacheTable is for caching the replies in order to
  497.    avoid repeated requests for the same destination addresses.
  498.  
  499.  
  500.  
  501. Heinanen & Govindan     Expires February 8, 1994                [Page 9]
  502.  
  503. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  504.  
  505.  
  506. 6.  Discussion
  507.  
  508.    The result of an NHRP request depends on how routing is configured
  509.    among the RSs.  If the destination terminal is directly connected to
  510.    the NBMA and the RSs always prefer NBMA routes over routes via other
  511.    link layer networks, the NHRP replies always return the NBMA address
  512.    of the destination terminal itself rather than the NBMA address of
  513.    some egress router.  For destinations outside the NBMA, egress
  514.    routers and routers in the other link layer networks should exchange
  515.    routing information so that the optimal egress router is always
  516.    found.
  517.  
  518.    In addition to RSs, an NBMA terminal could also be associated with
  519.    one or more regular routers that could act as "connectionless
  520.    servers" for the terminal.  Then the terminal could choose to resolve
  521.    the NBMA next hop or just send the IP packets to one of the
  522.    terminal's connectionless servers.  The latter option may be
  523.    desirable if communication with the destination is short-lived and/or
  524.    doesn't require much network resources.  The connectionless servers
  525.    could, of course, be physically integrated in the RSs by augmenting
  526.    them with IP switching functionality.
  527.  
  528.    NHRP supports portability of NBMA terminals.  A terminal can be moved
  529.    anywhere within the NBMA and still keep its original IP address as
  530.    long as its RS(s) remain the same.  Requests for authoritative
  531.    information will always return the correct link layer address.
  532.  
  533. References
  534.  
  535.    [1] Address Resolution Protocol, David C. Plummer, RFC 826.
  536.  
  537.    [2] Classical IP and ARP over ATM, Mark Laubach, Internet Draft.
  538.  
  539. Acknowledgements
  540.  
  541.    We would like to thank John Burnett of Adaptive, Dennis Ferguson of
  542.    ANS, Joel Halpern of Network Systems, and Paul Francis of Bellcore
  543.    for their valuable insight and comments to earlier versions of this
  544.    draft.
  545.  
  546. Authors' Addresses
  547.  
  548.    Juha Heinanen                           Ramesh Govindan
  549.    Telecom Finland,                        Bell Communications Research
  550.    PO Box 228,                             MRE 2P-341, 445 South Street
  551.    SF-33101 Tampere,                       Morristown, NJ 07960
  552.    Finland
  553.  
  554.  
  555.  
  556.  
  557. Heinanen & Govindan     Expires February 8, 1994               [Page 10]
  558.  
  559. INTERNET DRAFT                 NBMA NHRP                  August 8, 1993
  560.  
  561.  
  562.    Phone: +358 49 500 958                  Phone: +1 201 829 4406
  563.    Email: Juha.Heinanen@datanet.tele.fi    Email: rxg@thumper.bellcore.com
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613. Heinanen & Govindan     Expires February 8, 1994               [Page 11]
  614.  
  615.  
  616.